Kerberos Authentication

Kerberos is an authentication key agreement protocol

This means Kerberos allows 2 entities to establish a shared secret key securely, starting from an insecure communication channel.

Note this is also what happens in the web. In the web, however, when using HTTPS, we have the TLS protocol which works by using the ~X.509 digital certificates to authenticate entities (and a lot of other things) which are implemented via public-key cryptography.

In kerberos entities aren't authenticated by digital certificates, instead they can rely on a centralised server known as the KDC, that knows a long-term secret key for each entity involved in the communication. By using such knowledge it's possible to establish ephemeral session keys allowing clients to authenticate to services.

Kerberos is built on top of the Needham-Schroeder Symmetric Key Protocol.

Key Distribution Center (KDC)

A core Kerberos component dealing with initial authentication and issuing of tickets

This is made of 2 specific services:

Authentication Server (AS)

• After verifying the user identity it generates a TGT, these tickets can then be exchanged for Service Tickets

Ticket Granting Server (TGS)

• Component responsible for issuing Service Tickets by using the TGT

The Service Tickets allow users to access server resources

Realm

A Kerberos realm defines a logical security boundary that contains a group of principals (users, services and computers) that trust a specific KDC for authentication. In AD, a realm is automatically created when a domain is initialised. The Kerberos realm is the uppercase version of the AD domain name. I.e. nd.lab will be ND.LAB.

Remember - the Realm is a Grouping of Principals

To discover the realm your user is currently in, execute this cpmmand that prints the User Principal Name (UPN).

whoami /upn

You can also use this command

klist

There is also a service ticket present, used to connect with LDAP.

Principal

A Kerberos Principal is a unique identity to which Kerberos can assign tickets.

There are different principal types.

User Principal

• Also known as the User Principal Name (UPN)

As an example, the Kerberos principal for the user Administrator.

Service Principal

• Represents a service that requires authentication and authorization to be accessed by its clients

Example of services

• SMB service
• SQL server
• LDAP server - remember our service principal from earlier?
• HTTP server

Services need to register proper SPNs within AD. Once this registration has taken place, Kerberos can issue tickets for service access.

Host Principal

• Represents a computer in a Kerberos realm

Each principal has an associated secret key which is used during the key agreement protocol to provide authentication.

primary/instance@REALM

Primary - Identifies the entity
Instance - Further qualifies the primary
Realm - The Kerberos domain in which the authentication has to take place

List all SPNs registered for the host DC

setspn -L <DC_NAME>

Note the LDAP SPN

Set up a new SPN for the username

setspn -A HTTP/webserver.nd.lab oscar2
setspn -L leo